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Abstract 


The IPsec series of protocols makes use of various cryptographic 
algorithms in order to provide security services. The Internet Key 
Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate 
which algorithms should be used in any given association. However, 
to ensure interoperability between disparate implementations, it is 
necessary to specify a set of mandatory-to-implement algorithms to 
ensure that there is at least one algorithm that all implementations 
will have available. This document defines the current set of 
algorithms that are mandatory to implement as part of IKEv2, as well 
as algorithms that should be implemented because they may be promoted 
to mandatory at some future time. 


1. Introduction 


The Internet Key Exchange protocol provides for the negotiation of 
cryptographic algorithms between both endpoints of a cryptographic 


association. Different implementations of IPsec and IKE may provide 
different algorithms. However, the IETF desires that all 
implementations should have some way to interoperate. In particular, 
this requires that IKE define a set of mandatory-to-implement 
algorithms because IKE itself uses such algorithms as part of its own 
negotiations. This requires that some set of algorithms be specified 
as "mandatory-to-implement" for IKE. 
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The nature of cryptography is that new algorithms surface 
continuously and existing algorithms are continuously attacked. An 
algorithm believed to be strong today may be demonstrated to be weak 
tomorrow. Given this, the choice of mandatory-to-implement algorithm 
should be conservative so as to minimize the likelihood of it being 
compromised quickly. Thought should also be given to performance 
considerations as many uses of IPsec will be in environments where 
performance is a concern. 


Finally, we need to recognize that the mandatory-to-implement 
algorithm(s) may need to change over time to adapt to the changing 
world. For this reason, the selection of mandatory-to-implement 
algorithms was removed from the main IKEv2 specification and placed 
in this document. As the choice of algorithm changes, only this 
document should need to be updated. 


Ideally, the mandatory-to-implement algorithm of tomorrow should 
already be available in most implementations of IPsec by the time it 
is made mandatory. To facilitate this, we will attempt to identify 
those algorithms (that are known today) in this document. There is 
no guarantee that the algorithms we believe today may be mandatory in 
the future will in fact become so. All algorithms known today are 
subject to cryptographic attack and may be broken in the future. 


2. Requirements Terminology 


Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and 
"MAY" that appear in this document are to be interpreted as described 
in [RFC2119]. 


We define some additional terms here: 


SHOULD+ This term means the same as SHOULD. However, it is likely 
that an algorithm marked as SHOULD+ will be promoted at 
some future time to be a MUST. 


SHOULD- This term means the same as SHOULD. However, an algorithm 
marked as SHOULD- may be deprecated to a MAY in a future 
version of this document. 


MUST- This term means the same as MUST. However, we expect at 
some point that this algorithm will no longer be a MUST in 
a future document. Although its status will be determined 
at a later time, it is reasonable to expect that if a 
future revision of a document alters the status of a MUST- 
algorithm, it will remain at least a SHOULD or a SHOULD-. 
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3. Algorithm Selection 

3.1. IKEv2 Algorithm Selection 

3.1.1. Encrypted Payload Algorithms 
The IKEv2 Encrypted Payload requires both a confidentiality algorithm 
and an integrity algorithm. For confidentiality, implementations 
MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For 
integrity, HMAC-SHA1 MUST be implemented. 


3.1.2. Diffie-Hellman Groups 


There are several Modular Exponential (MODP) groups that are defined 
for use in IKEv2. They are defined in both the [IKEv2] base document 


and in the MODP extensions document. They are identified by group 
number. Any groups not listed here are considered as "MAY be 
implemented". 

Group Number Bit Length Status Defined 

2 1024 MODP Group MUST- [RFC2409] 

14 2048 MODP Group SHOULD+ [RFC3526] 


3.1.3. IKEv2 Transform Type 1 Algorithms 


IKEv2 defines several possible algorithms for Transfer Type 1 


(encryption). These are defined below with their implementation 
status. 
Name Number Defined In Status 
RESERVED 0 
ENCR_3DES 3 [RFC2451] MUST- 
ENCR_NULL 11 [RFC2410] MAY 
ENCR_AES_CBC 12 [AES-CBC] SHOULD+ 
ENCR_AES_CTR 13 [AES-CTR] SHOULD 


3.1.4. IKEv2 Transform Type 2 Algorithms 


Transfer Type 2 Algorithms are pseudo-random functions used to 
generate random values when needed. 


Name Number Defined In Status 
RESERVED (0) 

PRF_HMAC_MD5 A: [RFC2104] MAY 
PRF_HMAC_SHA1 2 [RFC2104] MUST 
PRF_AFS128 CBC 4 [AESPRF ] SHOULD+ 
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oe 


4. 


1.5. IKEv2 Transform Type 3 Algorithms 


Transfer Type 3 Algorithms are Integrity algorithms used to protect 
data against tampering. 


Name Number Defined In Status 
NONE 0 

AUTH_HMAC_MD5_96 al: [RFC2403] MAY 
AUTH_HMAC_SHA1_96 2 [RFC2404] MUST 
AUTH_AES_XCBC_96 5 [AES—MAC] SHOULD+ 


Security Considerations 


The security of cryptographic-—based systems depends on both the 
strength of the cryptographic algorithms chosen and the strength of 
the keys used with those algorithms. The security also depends on 
the engineering of the protocol used by the system to ensure that 
there are no non-cryptographic ways to bypass the security of the 
overall system. 


This document concerns itself with the selection of cryptographic 
algorithms for the use of IKEv2, specifically with the selection of 
"mandatory-to-implement" algorithms. The algorithms identified in 
this document as "MUST implement" or "SHOULD implement" are not known 
to be broken at the current time, and cryptographic research so far 
leads us to believe that they will likely remain secure into the 
foreseeable future. However, this isn’t necessarily forever. We 
would therefore expect that new revisions of this document will be 
issued from time to time that reflect the current best practice in 
this area. 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
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attempt made to obtain a general license or permission for the use of 
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